Remote transmission system

ABSTRACT

A virtual broadband receiver includes a receiving unit to receive a multiplicity of media data streams and an assembly engine to assemble them. The receiving unit receives the data streams from a multiplicity of data connections, wherein each media data stream was transmitted along one of at least one wireless communication network accessible from a remote reporting location to one of the data connections. The assembly engine assembles the data streams into a single media stream forming a live media transmission from the remote reporting location.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional application claiming benefit from U.S.patent application Ser. No. 11/845,071, filed Aug. 26, 2007, whichclaims benefit from U.S. Provisional Patent Application No. 60/847,148,filed Sep. 26, 2006, both of which are hereby incorporated by referencein their entirety.

FIELD OF THE INVENTION

The present invention relates to remote upload of media contentgenerally and to doing so over a wireless communications network inparticular.

BACKGROUND OF THE INVENTION

Remote upload of media content is known in the art. Such uploads aretypically used to provide real time, or near real time, coverage ofnews/sports events occurring outside of a prepared television studio.Camera crews are often sent to film live events in a variety oflocations and the video/audio feed is transmitted back to the studiowhere it is broadcast.

News/sports organizations use wireless broadband connections to transmitlive media content back to the studio. FIGS. 1A and 1B, to whichreference is now made, illustrate technologies currently used to providereal time remote broadcasts.

FIG. 1A shows a video camera 5 that is used to film a news event at aremote location. Camera 5 is connected by a cable 10 to a satellite newsgathering (SNG) van 15. SNG van 15 has an antenna 20 on its roof thattransmits broadcast data to a relay satellite 25 in orbit around theearth. Relay satellite 25 then transmits the data to a receiving dish 30at television studio 35.

SNG van 15 typically contains a variety of equipment (not shown), forexample, a video encoder, satellite modem and an editing station. Thisequipment is used to process and transmit the data to relay satellite25. SNG van 15 then uses a broadband connection to upload the data tosatellite 25 via antenna 20. The data is then downloaded to studio 35,where it is typically edited and broadcasted.

FIG. 1B illustrates how microwave technology is used for live remotebroadcasts. Functionally analogous to SNG 15 in FIG. 1A, electronic newsgathering (ENG) van 16 processes data from camera 5 before transmission.However, antenna 40 uploads the data using microwave transmissions, andinstead of relay satellite 25, the data is uploaded to relatively localmicrowave relay station 45. The data is then relayed to studio 35 viainternet 46 or a wire line connection 48.

Satellite and microwave technologies have similar operating constraints.For example, both technologies require “line of sight” connections.There must be an unobstructed line between antenna 20 and relaysatellite 25 in order to upload the broadcast data. Similarly, theremust be an unobstructed line between antenna 40 and microwave relaystation 45 in order to use microwave technology. Accordingly, thesetechnologies are inappropriate for use from some locations. For example,neither technology can be used from within an underground parkinggarage. Tall buildings and/or other topographic features impact on theusability of microwave technology, and to a lesser extent, that ofsatellite technology as well.

Another constraint is that both technologies require the prior agreementof the operator responsible for the relay installation. Neithertechnology can be used without the provision of dedicated resources bythe operator.

Furthermore, SNG and ENG vans 15 and 16 require serviceable roads toaccess remote broadcast locations. There are smaller, “luggable” unitsavailable, known as “flyaways” which may be used as an alternative toSNG and ENG vans 15 and 16. Flyaways may be brought to the remotelocation using other modes of transportation, including, for example,airplane, helicopter or all terrain vehicles. They are, however, stillbulky and difficult to carry far by hand. A flyaway is typically splitinto two separate units, each weighing approximately 40 kg.

Inmarsat, a United Kingdom company, markets a line of Broadband GlobalArea Network (BGAN) products which are considerably lighter and morecompact than flyaways. Such products, however, are limited to an uploadbandwidth of only 256 Kbps-512 Kbps.

SUMMARY OF THE INVENTION

There is therefore provided, in accordance with a preferred embodimentof the present invention, a virtual broadband receiver including a unitto receive a multiplicity of video data streams and an assembly engine.The unit to receive receives a multiplicity of video data streams from amultiplicity of data connections, wherein each video data stream wastransmitted along one of at least one wireless communication networkaccessible from a remote reporting location to one of the dataconnections. The assembly engine assembles the data streams into asingle video stream to form a live video transmission from the remotereporting location.

Moreover, in accordance with a preferred embodiment of the presentinvention, the data connections include connections to the Internet, aleased line network or a cellular network.

Further, in accordance with a preferred embodiment of the presentinvention, the video data streams include video data, audio data orboth.

Still further, in accordance with a preferred embodiment of the presentinvention the data streams include a series of data packets with serialnumbers wherein the data packets arrive in a generally non serial order.

Additionally, in accordance with a preferred embodiment of the presentinvention, the assembly engine includes a jitter buffer includingstorage spaces for the data packets to be inserted in logical orderaccording to the serial numbers.

Moreover, in accordance with a preferred embodiment of the presentinvention, the jitter buffer also includes a unit to view a logicalreceiving window including an area of the jitter buffer associated withthe data packets possessing generally recently issued the serialnumbers, a unit to view a logical retransmission window including anarea of the jitter buffer associated with the data packets possessingless recently issued the serial numbers than those associated with thelogical receiving window and a unit to view a logical output windowincluding an area of the jitter buffer associated with the data packetspossessing less recently issued the serial numbers than those associatedwith the logical receiving window.

Further, in accordance with a preferred embodiment of the presentinvention, the data packets also include FEC data.

Moreover, in accordance with a preferred embodiment of the presentinvention, the assembly engine also includes a FEC decoder to use theFEC data to reconstruct improperly received data packets and to insertthe reconstructed data packets into the smart jitter buffer as per theirassociated the serial numbers.

Further, in accordance with a preferred embodiment of the presentinvention, the assembly engine also includes a retransmit requester torequest retransmission of the missing data packets whose associatedserial numbers are logically located in the retransmission window.

Still further, in accordance with a preferred embodiment of the presentinvention, the receiver also includes a back channel through which theretransmit request can be transmitted and a back channel manager tocontrol the operations of the back channel.

Additionally, in accordance with a preferred embodiment of the presentinvention, the receiver also includes a statistics collector to collectstatistics from the operation of the smart jitter buffer. For example,the statistics may include time stamps and the serial numbers associatedwith at least one of the following: the data packets, the empty spaces,the reconstructed data packets, and the retransmission requests.

Moreover, in accordance with a preferred embodiment of the presentinvention, the receiver also includes an output rate controller toregulate the rate at which the data packets are released from the outputwindow.

Additionally, in accordance with a preferred embodiment of the presentinvention, the receiver also includes a video decoder to decode videodata included in the data packets.

There is also provided, in accordance with a preferred embodiment of thepresent invention, a method including receiving a multiplicity of videodata streams from a multiplicity of data connections, wherein each videodata stream was transmitted along one of at least one wirelesscommunication network accessible from a remote reporting location to oneof the data connections, and assembling the data streams into a singlevideo stream forming a live video transmission from the remote reportinglocation.

Moreover, in accordance with a preferred embodiment of the presentinvention, the assembling includes using a jitter buffer to arrange thedata packets in a logical order.

Further, in accordance with a preferred embodiment of the presentinvention, the method also includes sending retransmission requests formissing data packets that are logically associated with theretransmission window.

Additionally, in accordance with a preferred embodiment of the presentinvention, the method also includes tracking performance statistics forthe assembling and transmitting the performance statistics to the remotereporting location. For example, the performance statistics includeperformance details for modems used to upload the data packets from theremote reporting location. The performance details may include themissing data packets, the invalid data packets, retransmission requestsfor the data packets or the length of transmission time for the datapackets.

Finally, in accordance with a preferred embodiment of the presentinvention, the method also includes analyzing the performancestatistics, determining required changes to operational settings as perthe analyzing and transmitting the required changes to the remotereporting location.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter regarded as the invention is particularly pointed outand distinctly claimed in the concluding portion of the specification.The invention, however, both as to organization and method of operation,together with objects, features, and advantages thereof, may best beunderstood by reference to the following detailed description when readwith the accompanying drawings in which:

FIGS. 1A and 1B are schematic illustrations of prior art systems forremote broadcasting;

FIG. 2 is a schematic illustration of a novel virtual broadband system,constructed and operative in accordance with the present invention;

FIG. 3 is a schematic illustration of a virtual broadband transmittingunit, constructed and operative in accordance with the presentinvention;

FIG. 4 is a schematic illustration of the inputs and outputs of a packetinterleaves, constructed and operative in accordance with the presentinvention;

FIG. 5 is a schematic illustration of the flow of data packets through amultiplicity of modems, constructed and operative as a part of thesystem of FIG. 2;

FIG. 6 is a schematic illustration of a virtual broadband receivingunit, constructed and operative in accordance with the presentinvention;

FIG. 7 is a schematic illustration of arriving data packets as they aresorted in a smart jitter buffer, constructed and operative in accordancewith the present invention; and

FIGS. 8A and 8B are schematic illustrations of a smart jitter buffer,constructed and operative in accordance with the present invention.

It will be appreciated that for simplicity and clarity of illustration,elements shown in the figures have not necessarily been drawn to scale.For example, the dimensions of some of the elements may be exaggeratedrelative to other elements for clarity. Further, where consideredappropriate, reference numerals may be repeated among the figures toindicate corresponding or analogous elements.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the invention.However, it will be understood by those skilled in the art that thepresent invention may be practiced without these specific details. Inother instances, well-known methods, procedures, and components have notbeen described in detail so as not to obscure the present invention.

Applicants have realized that for the purpose of remote media uploads,cellular phone networks have several advantages. For example, suchnetworks do not require line of sight connections and they may be used,for example, in closed buildings, underground garages, narrow alleys,and other venues.

It will be appreciated that the broadband services provided by mobilenetwork operators are typically asymmetric. They generally providegreater bandwidth for the download of data and only limited bandwidthfor uploading data. For example, 1 megabit per second may be providedfor data downloads, whereas only 64 kilobits per second may be providedfor data upload. Applicants have realized that multiple cellular devicesmay be used in concert in order to create a “virtual broadband” uploadconnection. In such a virtual broadband upload connection (virtualbroadband connection), the sum total of the upload capacity of thedevices may represent enough combined bandwidth to facilitate agenerally live media transmission.

Reference is now made to FIG. 2 which illustrates a novel virtualbroadband system 100 for the remote transport of live media data over acellular network, constructed and operative in accordance with thepresent invention. As in the prior art, video camera 5 may be used tofilm news events at a remote location. Cable 10 may connect camera 5 toa virtual broadband upload unit 110, which may operate several cellularmodems 112 to transmit media data through one or more cellular corenetworks 120. Each modem 112 may generate a separate logical channel 115and the multiple channels 115 may constitute a virtual broadbandconnection 118.

It will be appreciated that, depending on the number of channels 115,the combined upload capacity of virtual broadband connection 118 mayapproximate that of a single, line of sight satellite or microwaveconnection.

From networks 120, the data may be transported to a virtual broadbandreceiver 130 via Internet connections 122, leased lines connections 124,cellular network connections 126 or any mix of the above connections.Virtual broadband receiver 130 may be located within studio 35, whichmay then broadcast the data to televisions, to the Internet, etc.

Networks 120 may be one or more cellular networks accessible from theremote location. It will be appreciated that one or more operators mayprovide such networks and that networks 120 may also use more than onetechnology. Accordingly, it will be appreciated that virtual broadbandconnection 118 may be comprised of a multiplicity of channels 115 beingtransmitted to one or more network operators, each of which operator maybe operating one or more networks of possibly different technologies.

Channels 115 may be transported to virtual broadband receiver 130 via anumber of routes, including, for example, Internet connection 122,leased line connection 124 and cellular network connection 126. Asdescribed hereinbelow, virtual broadband receiver 130 may accept datafrom a number of sources for processing.

It will be appreciated that the existing cellular communications systemis designed to provide mobile connectivity. Accordingly, virtualbroadband unit 110 may be significantly lighter than and more easilytransported than the satellite and microwave systems of the prior art.

Reference is now made to FIG. 3 which details an exemplary virtualbroadband unit 110. Virtual broadband upload unit 110 may comprise avideo encoder 131, a configurable stream processor 140, and a trafficanalyzer 150. As described hereinbelow, configurable stream processor140 may process an incoming video stream 135, from video encoder 131, toprovide multiple upload streams 195, one per modem 112 (FIG. 2). Trafficanalyzer 150 may configure the settings of configurable stream processor140 based on current statistical feedback received via one or more backchannels 190. Batteries (not shown) may also be included to provide amobile power source.

Configurable stream processor 140 may comprise a forward errorcorrection (FEC) module 155, a packet encapsulator 160, an interleaver165, a queue generator 170, multiple modem managers 175, multiple modemdrivers 180 and a retransmit mechanism 185. Video stream 135, which isinput to configurable stream processor 140, may be encoded, for examplewith H.264 encoding, or it may be unencoded.

FEC processor 155 may initially divide the data of video stream 135 intopackets and it may add extra packets with FEC codes. FEC codes consistof information that may be used to reconstruct missing or improperpackets if the need arises. In an exemplary FEC scheme, FEC processor155 may add an additional 10% of packets to the stream. If some packetsare lost or improperly received, the FEC codes may be used toreconstruct the missing packets. It will be appreciated that the FECpercentage and the number of packets in a FEC grouping may beconfigurable. Configuration may generally be performed whenever a newchannel 115 (FIG. 2) is opened. Reconfiguration may thus be performedwhenever a new channel is opened or an existing one is changed. Anysuitable algorithm may be used for FEC processor 155, for example,Reed-Solomon.

Packet encapsulator 160 may add serial numbers and time stamps to eachvideo and FEC packet.

The packets may then proceed to interleaver 165. Interleaving mayattempt to minimize the impact of packets lost as a result of a break intransmission. The packets may be “shuffled”, resulting in an outputorder which may reduce exposure to the loss of consecutive packets dueto a given transmission error. FIG. 4, to which reference is now brieflymade, illustrates the operation of interleaver 165. Input packet queue166 may have packets received in consecutive order 1, 2, 3, 4, etc. (asdetermined by the packet numbers assigned by packet encapsulator 160).Output packets 167 may be “interleaved”; the order may have beenrandomized such that consecutive packet numbers are no longer adjacentto one another. In FIG. 4, output packets 167 have the order 4, 7, 12,1, 5, etc.

Interleaved packets 167 are then forwarded to queue generator 170 (FIG.3) where they remain in a queue until pulled from the queue by one ofthe multiple modem managers 175. There may typically be one modemmanager 175 for each modem 112 (FIG. 2). For every modem manager 175,there may be an associated modem driver 180. Modem drivers 180 maymanage the individual modems 112 used to transmit the packets.

After a packet has been pulled by modem manager 175, a copy of itsphysical data may be forwarded to retransmission queue 185 where it mayremain in place until its space is required for a new packet.Accordingly, the packet may still be available for retransmission for aperiod of time after it is initially pulled by one of the modem managers175. Retransmit mechanism 185 may search retransmission queue 185 for apacket needed for retransmission. Once the required packet is found, itmay be advanced to the head of the queue so that the relevant modemmanager 175 may retransmit it as quickly as possible.

Reference is now briefly made to FIG. 5, which illustrates how modemmanagers 175 may pull packets from queue generator 170 and may forwardthem to modem drivers 180. Queue generator 170 may comprise an outputbuffer 171 and a buffer controller 172. As shown, output buffer 171 maycontain interleaved packets 173 waiting to be pulled by modem managers175. Four modem managers 175A, 175B, 175C and 175D are shown. Each modemmanager 175(A,B,C,D) may be associated with one modem driver180(A,B,C,D), which in turn manages one associated modem 112(A,B,C,D).

Each modem 112 may have different performance characteristics. Forexample, modem 112B may be capable of the highest connection speed.Modem 112C may be capable of a similar speed, but may have a higher rateof observed errors. Modem 112D may be relatively slow, but it mayexperience very few errors. Modem 112A may be a high quality, state ofthe art modem, but it may connect with a core network 120 (FIG. 2) thatcurrently has a high error rate. It will thus be appreciated that avariety of factors may impact on the actual performance of a given modem112. Such factors may include, for example, modem speed, modemreliability, connection quality, operating license limitations, andnetwork congestion. It will further be appreciated that such factors maynot be constant; a given modem 112 may perform at different levels overthe course of a short period of time.

Therefore, each modem manager 175 may be configured to “feed” itsassociated modem driver 180 as per a rate optimal under the currentprevailing conditions. Accordingly, as per the example illustrated byFIG. 5, modem manager 175B may be assigned a very high rate; seven ofthe seventeen packets 173 shown may be forwarded through modem driver180B. Modem managers 175C and 175D may be assigned a lower rate, eachpassing only four packets 173 to modem drivers 180C and 180Drespectively. Modem manager 175A may be assigned a still lower rate. Itmay pass only two packets 173 to modem driver 180A.

Accordingly each modem manager 175 may query buffer controller 172 at adifferent rate for the next available packet 173. It will beappreciated, that in such a manner already interleaved packets 173 areinequitably distributed amongst modems 112, thus effectively undergoinga second interleaving process.

As packets 173 are pulled by modem managers 175, buffer controller mayrecord the packet number and the modem manager 175 which transferred itfor transmission in a pulled packet table 174. As described hereinbelow,table 174 may be used to analyze the performance of individual modems112.

It will also be appreciated, as noted hereinabove, that the performanceof each modem 112 may change during the course of a given uploadsession. It will further be appreciated that the overall performancetrend for all of the involved modems 112 may also change during thecourse of an upload session. Therefore, in accordance with a preferredembodiment of the preset invention, traffic analyzer 150 (FIG. 3) mayanalyze actual performance statistics from the ongoing upload session inorder to improve the settings for configurable IP stream processor 140.

Returning to FIG. 3, multiple back channels 190 may pass performancedata from virtual broadband receiver 130 (FIG. 2) to traffic analyzer150. Such data may include, for example, time stamps for the arrival ofpackets, missing packet numbers, packet numbers with errors, andrequests to retransmit packets.

Traffic analyzer 150 may forward such retransmission requests toretransmit mechanism 185. It will be appreciated that since duplicatedata may be transmitted via each of multiple back channels 190, multiplecopies of such retransmission requests may be received by retransmitmechanism 185. Accordingly retransmit mechanism 185 may track thereceipt of such requests, and ignore any duplicates. Mechanism 185 maythen process such requests as already described hereinabove.

Traffic analyzer 150 may also query pulled packet table 174 of queuegenerator 170 to associate the packet numbers received via back channel190 with the modem managers 175 that processed the original packets.Traffic analyzer 150 may analyze this information to detect performancetrends among the modems 112. If a modem 112 has a high, or rising, rateof errors, missing packets or delay, traffic analyzer 150 may instructthe associated modem manager 175 to lower its rate or even shut down itsassociated modem 112. Similarly, in response to a reduction in errors,missing packets and/or delay, traffic analyzer 150 may instruct theassociated modem manager 175 to raise the transmission rate of itsassociated modem 112.

Traffic analyzer 150 may also seek to balance rates among modem managers175. For example, if several modem managers 175 are instructed to lowerrates, then the other modem managers 175 may be instructed to raisetheir rates to compensate for the anticipated reduction in overallthroughput.

Traffic analyzer 150 may also identify overall performance trends. Forexample, current statistics may indicate that few, if any, packets arebeing lost. In such a case, traffic analyzer 150 may instructinterleaver 165 to reduce the level of interleaving. Another exemplarytrend may include an overall higher level of errors detected. In such acase, traffic analyzer 150 may instruct FEC processor 155 to increasethe FEC overhead or to alter the compression rate of the video datareceived from encoder 131.

An overall high level of errors and missing packets may result in asituation in which the combined rate of all of the modem managers 175may be insufficient to transmit all of video stream 135 in a timelymanner. In such a case, traffic analyzer 150 may use feedback channel198 to instruct video encoder 131 (FIG. 3) to increase the compressionrate in order to reduce the bandwidth required to transmit video stream135 after processing.

Reference is now made to FIG. 6 which details virtual broadband receiver130, constructed and operated in accordance with a preferred embodimentof the present invention. Receiver 130 may comprise an assembly engine200, an output rate controller 220, a packet decapsulator 225 and afeedback manager 250.

Assembly engine 200 may receive multiple streams 201, via connections122, 124 and/or 126, for processing. The assembled stream, labeled 206,may then be forwarded to output rate controller 220, which in turn mayforward it to packet decapsulator 225 to remove the extra packetinformation. The resulting media data stream 230 may then be output fromvirtual broadband receiver 130 to TV station 35 (FIG. 2). Feedbackmanager 250 may receive retransmit requests from assembly engine 200 andmay collect the statistics of the incoming streams 201. Feedback manager250 may also provide the retransmit requests and the statistics alongback channel 190 to traffic analyzer 150 (FIG. 3).

As mentioned hereinabove, multiple streams 201 may be received fromseveral different connections, for example, Internet connections 122,leased line connections 124, and/or cellular network connections 126.Regardless of the connections used for transmission, the packets instreams 201 may be input to assembly engine 200 as is, per their orderof arrival.

Assembly engine 200 may comprise a smart jitter buffer 205, an FECdecoder 215, and a retransmit requester 210. FEC decoder 215 may be anysuitable FEC decoder, such as is known in the art and compatible withthe FEC used in the virtual broadband upload unit 110. Smart jitterbuffer 205 may serve two purposes: it may be the area where the packetsof streams 201 are “de-interleaved”, and it may also provide a frameworkfor use by FEC and retransmit mechanisms 215 and 210 while resolvingmissing packets.

Reference is now briefly made to FIG. 7 which illustrates how packets203 from streams 201 may be placed into smart jitter buffer 205. Anexemplary size for smart jitter buffer may be 100-1000 msec. Four inputstreams 201A, 201B, 201C and 201D are shown as is a timestamp, from 0 to24, where 0 is the rightmost timestamp. Accordingly, packet #3, arrivingat timestamp 0, may be the first packet 203 to be processed.

Smart jitter buffer 205 may have consecutively numbered bins, where, inFIG. 7, the bins are labeled from 1 to 17. As each packet 203 isreceived, it may be placed in its associated bin, according to itspacket number. Thus, packet #3 which arrived first, may be placed in bin3. The packets stored in buffer 205 may therefore represent packets 203in their original order, even though their order of arrival may havebeen 3,5,8,4,7.

In the example of FIG. 7, packets 1, 2 and 6 are still missing. Thus,buffer 205 may indicate which packets have not arrived.

Reference is now made to FIGS. 8A and 8B which illustrate how FECdecoder 215 and retransmit requester 210 make use of smart jitter buffer205. FIG. 8A shows how retransmit requester 210 may logically dividebuffer 205 into three windows: an output window 211, a retransmissionwindow 212, and a receiving window 213. Output window 211 may store thedata to be transmitted as serial packet stream 206.

It will be appreciated that windows 211, 212, and 213 may not be fixedin static locations vis-à-vis smart jitter buffer 205. They may insteadbe dynamically defined in terms of offsets from the most recent packet203 to be output from smart jitter buffer 205. FIG. 8A thus represents asnapshot in time, where output window 211 stores an exemplary sixpackets waiting for output, of which packet #1 may be the first in line.Once packet #1 has been added to serial packet stream 206, output window211 may shift to include packets #2-7.

Therefore, it will also be appreciated that packets 203 may not changephysical position once placed in smart jitter buffer 205. In actuality,a constant shifting of windows 211, 212, and 213 may result in theillusion of “movement” along the buffer. Accordingly, it will beappreciated that any discussion hereinbelow regarding movement orprocession by packets 203 within smart jitter buffer 205 may refer onlyto logical movement as defined by the shifting of windows 211, 212, and213.

As discussed hereinabove, packets 203 may not arrive in serial order,particularly as they may have been interleaved prior to transmission andmay have been transmitted and/or received via multiple connections andchannels. Accordingly, as packets 203 may be received, they may beplaced in receiving window 213 in order according to their packetnumber. An exemplary size for receiving window 213 may be 50-400 ms. Noaction may be taken to replace missing packets 203 at this stage; theremay be a reasonable assumption that any missing packets may still arrivewithout added processing. For example, in FIG. 8A, packet #17 may notyet have arrived because it was transmitted after packets 16-23 (due tointerleaving, for example). For this purpose, retransmission window 213may be large, of, for example 200-1000 msec.

Packets 203 may then proceed to retransmission window 212. This windowmay define a window of opportunity to request retransmission of missingpackets 203. As described hereinabove, prior to this stage it may beunnecessary to request retransmission, since it may still be likely thata missing packet may arrive in any case. Conversely, subsequent to thisstage, it may be too late to request a retransmission, since such arequest requires a certain amount of turn around time to complete—therequest must first reach virtual broadband unit 110 (FIG. 2) and thenthe retransmitted packet 203 must still arrive in a timely manner to beadded to serial packet stream 206. Accordingly, a retransmit threshold214 may define a point at which retransmit requests may no longer be aviable option for a given packet 203.

As per the exemplary data in FIG. 8A, packet #10 may be missing fromretransmission window 212. Retransmit requester 210, which may viewretransmission window 212, may therefore submit a retransmission requestto feedback manager 250. Retransmit requester 210 may submit one or moresuch requests as long missing packet #10 is “located” withinretransmission window 212. The timing for such requests may beconfigurable.

It will be appreciated that the size and location of retransmissionwindow 212 may be configurable. For example, when there is a low rate ofmissing packets, it may be possible to use a small window 212, such asonly 200 msec. If a virtual broadband unit 110 has fast modems, it maybe possible to reduce the size of output window 211 in light of the factthat turn around time for retransmission may be quicker. It will,therefore, also be appreciated that the size and location ofretransmission window 212 may effectively determine the size andlocation of windows 211 and 213.

Packets 203 may then proceed to output window 211. As describedhereinabove, once a missing packet 203 has reached output window 211, nomore retransmit requests may be sent on its behalf. It will beappreciated, however, that missing packets 203 may still arrive and beplaced in output window 211. For example, a retransmit request may havepreviously been submitted from retransmission window 213 for packet #2.If packet #2 may arrive in time it may still be placed as per its serialorder in output window 211.

FIG. 8B shows how FEC decoder 215 may divide buffer 205 into threewindows similar to those used by retransmit requester 210: an outputwindow 216, an activation window 217, and a receiving window 218. Outputwindow 216 may be defined as starting from an FEC threshold 219 and maygenerate serial packet stream 206. Once again, it will be appreciatedthat any discussion hereinbelow regarding movement or procession bypackets 203 within smart jitter buffer 205 may refer only to logicalmovement as defined by the shifting of windows 216, 217, and 218.

Functionally, output window 216 and receiving window 218 may beequivalent to windows 211 and 213 respectively, as defined forretransmit requester 210. Missing packets 203 may not be addressed whilestill in receiving window 218, and no further processing may beinitiated for missing packets 203 that have passed FEC threshold 219 andentered output window 216. However, similar to the relationship betweenwindow 212 and windows 211 and 213, the size and location of windows 216and 218 may be determined by the size and location of activation window217. Accordingly, even though windows 216 and 218 are functionallysimilar to windows 211 and 213, their respective sizes and locations maybe different.

Missing packets in activation window 217 may be reconstructed using theFEC codes of other packets 203 that have already arrived and been placedin smart jitter buffer 205. The size and location of activation window217 may therefore be functions of the FEC percentages used and theamount of time required to reconstruct a given packet 203.

For example, FIG. 8B shows window 217 as being an exemplary ten packets203 in size. This may illustrate a case where a FEC percentage has beendefined requiring nine received packets 203 in order to reconstruct atenth packet, for example, missing packet #10. FIG. 8B also shows anexemplary size of five packets 203 for output window 216. This mayillustrate a case where the time required to reconstruct a missingpacket may be close to the time that it may take for five packets 203 tobe output.

It will be appreciated that the sizes and locations of bothretransmission window 212 and activation window 217 may be exemplary.Other sizes and locations may be configured as per specific requirementsand/or prevailing conditions. It will also be appreciated that the sizesand locations may be reconfigured during operation in order tocompensate for changing conditions and/or error rates. It will furtherbe appreciated that both retransmit requester 210 and FEC decoder 215may use the same smart jitter buffer 205 simultaneously. Accordingly,mechanisms 210 and 215 may have configurable settings for precedence inorder to avoid conflicting and/or redundant actions.

Returning to FIG. 6, serial packet stream 206 from assembly engine 200may be forwarded to output rate controller 220. It will be appreciatedthat serial packet stream 206 may ultimately be intended for a livebroadcast over television. Accordingly, output rate controller 220 mayregulate the rate at which serial packet stream 206 is released in orderto maintain an appropriate broadcast rate.

The output of controller 220 may then be forwarded to packetdecapsulator 225, where the packet overhead, including, for example,packet numbering and timestamps, may be removed. The resulting mediastream 230 may then be broadcast and/or saved for later use.

Feedback manager 250 may comprise a statistics collector 255 and a backchannel manager 260. Statistics collector 255 may receive a constantstream of packet statistics from smart jitter buffer 205. Suchstatistics may include, for example, the numbers ofmissing/reconstructed packets, as well as time stamps and packet numbersfor packets received. Statistics collector 255 may then forward thesestatistics to back channel manager 260. Such statistics may be forwardedin a raw state with little or no pre-processing. Such statistics mayeventually be processed and analyzed by traffic analyzer 150 (FIG. 3).However, in accordance with an alternative preferred embodiment of thepresent invention, such processing may also be included in feedbackmanager 250.

Back channel manager 260 may also receive retransmit requests fromretransmit requester 210. Back channel manager 260 may then transmitsuch statistics and retransmit requests to virtual broadband unit 110(FIG. 3) via back channel 190. Back channel 190 may be any suitableconnection with virtual broadband unit 110.

As discussed hereinabove, by using such packet statistics, trafficanalyzer 150 may be able to optimize the quality and flow of themultiplicity of connections 115 (FIG. 2), thereby to create virtualbroadband connection 118. It will be appreciated that the combination ofsuch optimization with the error checking and correction features ofvirtual broadband receiver 130 may provide enhanced end-to-end qualityof service for system 100.

In an alternative embodiment of the present invention, non cellularwireless technologies may also be used for connections 115. For example,WiFi and/or WiMax and/or satellite (e.g. BGAN) technologies may be used,instead of, or in addition to cellular networks, to connect virtualbroadband unit 110 to the internet. Similarly, WiFi and/or WiMax and/orsatellite may be used by virtual broadband receiver 130 to receivestreams 201 (FIG. 6).

In another alternative embodiment of the present invention, virtualbroadband receiver 130 may be a mobile unit at a remote location. It mayreceive stream 201 via the same technologies used for transmitting, forexample, cellular networks, WiFi and/or WiMax.

In another alternative embodiment of the present invention, virtualbroadband unit 110 and virtual broadband receiver 130 may share wirelessresources and/or may even be housed in the same physical unit.

While certain features of the invention have been illustrated anddescribed herein, many modifications, substitutions, changes, andequivalents will now occur to those of ordinary skill in the art. It is,therefore, to be understood that the appended claims are intended tocover all such modifications and changes as fall within the true spiritof the invention.

1. A virtual broadband receiver comprising: means to receive amultiplicity of video data streams from a multiplicity of dataconnections, wherein each video data stream was transmitted along one ofat least one wireless communication network accessible from a remotereporting location to one of said data connections; and an assemblyengine to assemble said data streams into a single video stream to forma live video transmission from said remote reporting location.
 2. Thereceiver according to claim 1 wherein said data connections compriseconnections to at least one of the following types of network: theInternet, a leased line network and a cellular network.
 3. The receiveraccording to claim 1 and wherein said video data streams comprise atleast one of video and audio data.
 4. The receiver according to claim 1and wherein said data streams comprise a series of data packets withserial numbers wherein said data packets arrive in a generally nonserial order.
 5. The receiver according to claim 4 and wherein saidassembly engine comprises a jitter buffer comprising storage spaces forsaid data packets to be inserted in logical order according to saidserial numbers.
 6. The receiver according to claim 5 and wherein saidjitter buffer also comprises: means to view a logical receiving windowcomprising an area of said jitter buffer associated with said datapackets possessing generally recently issued said serial numbers; meansto view a logical retransmission window comprising an area of saidjitter buffer associated with said data packets possessing less recentlyissued said serial numbers than those associated with said logicalreceiving window; and means to view a logical output window comprisingan area of said jitter buffer associated with said data packetspossessing less recently issued said serial numbers than thoseassociated with said logical receiving window.
 7. The receiver accordingto claim 6 and wherein said data packets also comprise FEC data.
 8. Thereceiver according to claim 7 and wherein said assembly engine alsocomprises a FEC decoder to use said FEC data to reconstruct improperlyreceived data packets and to insert said reconstructed data packets intosaid smart jitter buffer as per their associated said serial numbers. 9.The receiver according to claim 7 and wherein said assembly engine alsocomprises a retransmit requester to request retransmission of saidmissing data packets whose associated said serial numbers are logicallylocated in said retransmission window.
 10. The receiver according toclaim 9 and also comprising: a back channel through which saidretransmit request can be transmitted; and a back channel manager tocontrol the operations of said back channel.
 11. The receiver of claim10 and also comprising a statistics collector to collect statistics fromthe operation of said smart jitter buffer.
 12. The receiver according toclaim 11 and wherein said statistics comprise time stamps and saidserial numbers associated with at least one of the following: said datapackets, said empty spaces, said reconstructed data packets, and saidretransmission requests.
 13. The receiver according to claim 6 and alsocomprising an output rate controller to regulate the rate at which saiddata packets are released from said output window.
 14. The receiveraccording to claim 1 and also comprising a video decoder to decode videodata included in said data packets.
 15. A method comprising: receiving amultiplicity of video data streams from a multiplicity of dataconnections, wherein each video data stream was transmitted along one ofat least one wireless communication network accessible from a remotereporting location to one of said data connections; and assembling saiddata streams into a single video stream forming a live videotransmission from said remote reporting location.
 16. The methodaccording to claim 15 and wherein said data streams comprise a series ofdata packets with serial numbers, wherein said data packets arrive in agenerally non serial order.
 17. The method according to claim 16 andwherein said assembling comprises using a jitter buffer to arrange saiddata packets in a logical order.
 18. The method according to claim 16and wherein said jitter buffer comprises the following logical windows:a receiving window, a retransmission window, and an output window. 19.The method according to claim 18 and also comprising sendingretransmission requests for missing said data packets that are logicallyassociated with said retransmission window.
 20. The method according toclaim 16 and also comprising: tracking performance statistics for saidassembling; and transmitting said performance statistics to said remotereporting location.
 21. The method according to claim 20 and whereinsaid performance statistics comprise performance details for modems usedto upload said data packets from said remote reporting location.
 22. Themethod according to claim 21 and wherein said performance detailscomprise at least one of the following: missing said data packets,invalid said data packets, retransmission requests for said datapackets, and length of transmission time for said data packets.
 23. Themethod according to claim 20 and also comprising: analyzing saidperformance statistics; determining required changes to operationalsettings as per said analyzing; and transmitting said required changesto said remote reporting location.